Skip to content

action.yml: Configure git to use HTTPS for GitHub repos#388

Closed
thomasheritage wants to merge 4 commits intomainfrom
thomash_replace_all_patch
Closed

action.yml: Configure git to use HTTPS for GitHub repos#388
thomasheritage wants to merge 4 commits intomainfrom
thomash_replace_all_patch

Conversation

@thomasheritage
Copy link
Collaborator

build.mjs runs a number of git commands including cloning repos (and their submodules). Any operation using SSH fails because SSH is not configured on the runner. For example, submodules might be configured using SSH (with "git@github.com" in ".gitmodules").

This commit configures git so that all uses of SSH for GitHub repos are automatically replaced with HTTPS. This is comparable to the behaviour of https://github.com/actions/checkout which notes "When the ssh-key input is not provided, SSH URLs beginning with git@github.com: are converted to HTTPS"

This is added to action.yml rather than to build.mjs because it aims to configure the runner environment -- if build.mjs is run in other contexts (e.g. local machine) then a different configuration might be needed.

build.mjs runs a number of git commands including cloning repos (and
their submodules). Any operation using SSH fails because SSH is
not configured on the runner. For example, submodules might be
configured using SSH (with "git@github.com" in ".gitmodules").

This commit configures git so that all uses of SSH for GitHub repos are
automatically replaced with HTTPS. This is comparable to the behaviour
of https://github.com/actions/checkout which notes "When the `ssh-key`
input is not provided, SSH URLs beginning with `git@github.com:` are
converted to HTTPS"

This is added to action.yml rather than to build.mjs because it aims to
configure the runner environment -- if build.mjs is run in other contexts
(e.g. local machine) then a different configuration might be needed.
@github-actions
Copy link

github-actions bot commented Mar 12, 2026

@thomasheritage
Copy link
Collaborator Author

Note that this will fix problems I'm actively having with redlines on ST 2067-206 as part of comment resolution

@SteveLLamb SteveLLamb requested a review from palemieux March 17, 2026 21:45
Copy link
Member

@palemieux palemieux left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why would submodules be configured with SSH?

What is the context of this proposed change?

@SteveLLamb
Copy link
Member

Why would submodules be configured with SSH?

What is the context of this proposed change?

I'll close this PR after chatting with Thomas directly, as per our discussion.

@SteveLLamb SteveLLamb closed this Mar 17, 2026
@thomasheritage
Copy link
Collaborator Author

Thanks for looking into this. Apologies, there might have been a bit of misunderstanding here because the discussion has been split between GitHub and email.

This PR ensures that git on the runner is configured so that it's robust against the protocol used when referring to git repos on GitHub -- that is, if SSH is used to refer to a repo (which will fail) it simply uses HTTPS instead (which will work). For example, if .gitmodules contains url = git@github.com:SMPTE/html-pub.git then https://github.com/SMPTE/html-pub.git will automatically be used instead.

This is useful because in the repo for ST 2067-206 I set url = git@github.com:SMPTE/html-pub.git in .gitmodules. I did this because I was using SSH for all my git access on my local development machine and so it seemed like an obvious thing to do (I think I was pushing some html-pub changes and only had GitHub auth configured for SSH. Instead I probably should have used git config submodule.tooling.url git@github.com:SMPTE/html-pub.git or git config --replace-all url."git@github.com:".insteadOf "https://github.com/". Alternatively, .gitmodules could contain a relative URL for html-pub rather than an absolute (SSH or HTTPS) URL). I didn't realise that the html-pub tooling was sensitive to the protocol specified in .gitmodules. AFAICT this is not documented anywhere.

@SteveLLamb thanks for the updates you've made to https://github.com/SMPTE/st2067-206-private. However, there is still a problem. In the PR "20260202 CD" (at https://github.com/SMPTE/st2067-206-private/pull/34) the step "Generating a redline against the latest edition tag: 20260202-wd" still fails (see https://github.com/SMPTE/st2067-206-private/actions/runs/23219441818/job/67488414326#step:6:659) because in that tagged release the .gitmodules file still specifies SSH for html-pub (see https://github.com/SMPTE/st2067-206-private/blob/20260202-wd/.gitmodules#L3). Of course that can't be changed without re-writing the git history or changing the tag etc (all very undesirable especially given that this marks what was sent to the TC for pre-FCD review).

(As an aside: note that although "Generating a redline against the latest edition tag: 20260202-wd" failed and there's no link to it in the post by the github-actions bot on the 2067-206 PR (see https://github.com/SMPTE/st2067-206-private/pull/34#issuecomment-4011917610) it was previously generated successfully (because I updated the "tooling" submodule to use the branch referenced by this html-pub PR) and is still accessible at https://doc.smpte-doc.org/st2067-206-private/20260202-cd1/pub-rl.html. I've emailed this link to people. This is dangerous because this redline is now out-of-sync with the other assets at https://doc.smpte-doc.org/st2067-206-private/20260202-cd1/ because of the S3 issue covered at #360)

I believe that the change made in this PR is (roughly) equivalent to the approach taken by the official actions/checkout action (see https://github.com/actions/checkout/blob/0c366fd6a839edf440554fa01a7085ccba70ac98/src/git-auth-helper.ts#L67) used by html-pub (see https://github.com/SMPTE/html-pub/blob/main/.github/workflows/main.yml#L33C15-L33C31).

This PR would solve the issue I'm having with 2067-206, and make html-pub more robust. Is there be a downside? Is there an alternative fix to the issues I'm having with 2067-206 that would be preferable?

@thomasheritage
Copy link
Collaborator Author

Note that the "base-rl.html" redline is being generated on https://github.com/SMPTE/st2067-206-private/pull/34 and it's basically the same as "pub-rl.html" (that isn't being generated at the moment) so people reviewing recent changes can just use that one for now. However, there will be a problem once #394 is merged because redline failure will then (sensibly) cause the whole build job to fail.

@SteveLLamb
Copy link
Member

@thomasheritage OH! I see the issue clearly now. There are 2 redlines avail:

  • Base redline ("Redline to current draft")
  • Pub redline ("Redline to most recent edition")
    Both generate on PR IF a .smpte-build.json tag is not null. Only Pub redline renders on main on a merge.

This we know. Now your issue:

  • You created the PR without a tag defined, got only the base redline (compared to current main),
  • Added the tag and then the PR didn't see the new tag and gen the Pub redline.

That was because the tag is fetched only at PR create build and stored, not each PR commit build (the root issue). There is no current git fetch --tags.

I'll make this update as part of the force fail PR at #394 ,as it's related.

@thomasheritage
Copy link
Collaborator Author

That was because the tag is fetched only at PR create build and stored, not each PR commit build

Is that correct? Both redlines were produced correctly on https://github.com/SMPTE/st2067-206-private/pull/34/changes/e4d6d2be759b335c4c4c15865990404675b33abb when I switched to my branch of html-pub (that has the SSH/HTTPS fix).

From the Action logs the error I am having is due to not being able to clone html-pub using SSH per https://github.com/SMPTE/st2067-206-private/actions/runs/23219441818/job/67488414326#step:6:659 :

fatal: clone of 'git@github.com:SMPTE/html-pub.git' into submodule path '/home/runner/work/st2067-206-private/st2067-206-private/build/ref/tooling' failed

@SteveLLamb
Copy link
Member

Nope, the root issue is the release having the updated url on the .gitmodules, I had to create a new release with teh proper one, and now all is working. The redlines are currently identical, but that is due to the main being the same as the release (as it was).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants